RSA, ECC, eller båda?

NSA (National Security Agency) har slutat rekommendera en övergång från det asymmetriska kryptot RSA till det lite modernare kryptot ECC (elliptic curve cryptography). Tongångarna har varierat över tid men det faktum att NSA kan ha olika intressen gör inte saken enklare att tolka bakomliggande orsaker. Det bör poängteras att NSA inte på något vis avråder från användning av ECC men att de inte längre uppmuntrar en övergång från RSA till ECC.

Om vi ändå försöker göra en tolkning av NSA’s rekommendation att hålla kvar vid den gamla RSA-algoritmen, istället för att gå över till ECC, så poppar det genast upp några frågor. Är det så att ECC har brister som ännu inte nått offentlighetens ljus? Är NSA’s förmågor begränsade vad gäller ECC? Eller är det ett inväntande av en ytterligare algoritm som inte kvantdatorerna lika lätt kan antas forcera?

Att all fakta för ett beslut inte finns tillgängligt hör till sakens natur. Att kvantdatorer i närtid skulle utgöra ett hot mot RSA och ECC är nog att betrakta som överdrivet. Åtminstone sett till det arbete som bekostas av amerikanska skattebetalare. Men, vilka förmågor finns i andra på området framstående länder?

Ett resonemang är att så väl ECC och RSA sannolikt på sikt går samma öde till mötes ungefär samtidigt och då kanske de ersätts av postkvantalgoritmer som gör dem båda till blott ett minne. Till dess måste vi dock välja väg. ECC, RSA, eller båda?

Det vi kan konstatera är att det inte finns några hårda bevis på att ECC skulle vara trasigt. Det går heller inte att bortse från den prestandaförbättring som ECC ger som i transaktionstäta sammanhang leder till avsevärda kostnadsbesparingar.

För den som inte har behov av de fördelar som ECC ger ligger det nära tillhands att stanna kvar vid RSA. För att inte falla offer för det faktum att RSA successivt bryts ner, vilket i praktiken innebär krav på längre nycklar över tid samt att byta ut dem periodiskt. Det är rekommendera att byta nycklar oftare och att använda längre nycklar (idag minst 2432, imorgon minst 3078). Nyckellängd ska balanseras med nyckelkvalitet och kryptografisk period för att säkerställa lämpliga nycklar som fyller avsett syfte.

Oavsett algoritmval så kan vi konstatera att ett frekventare nyckelbyte också ger en mer tränad organisation vilket leder till färre driftstörningar. Det är dessvärre inte ovanligt att nyckelbyten väljs bort för att undvika driftstörningar, vilket verkligen är kontraproduktivt på flera sätt.

Vad gäller längre RSA-nycklar ökar tyvärr risken för inkompatibilitet av den enkla anledningen att oväntat många har valt att inte implementera stöd för längre nycklar. Låt dock inte det bli ett hinder, utan växla hellre bort lösningar som inte förstår eller har förmågan att hänga med i utvecklingen. Alternativet är att de bidrar till onödigt riskexponering vilket knappast är önskvärt.

Förringa inte det ständiga behovet av underhåll av kryptoimplementationerna. Kodbibliotek, paketerade mjukvaror etc. behöver skyndsamt uppdateras för att hantera buggar och sårbarheter som löpande dyker upp som brev på posten. Sårbarheterna i exempelvis OpenSSL och Debian som fått stort medialt utrymme de senaste åren är dessvärre bara toppen på isberget. Behovet av löpande underhåll över tid försvinner inte bara för att det är säkerhetsrelaterad mjukvara, snarare tvärtom.

Oavsett ECC eller RSA så är det till syvendes och sist kvalitén på nyckelmaterialet som är den enskilt avgörande faktorn. Det är en betydligt viktigare faktor än någon annan (se flera tidigare krönikor för utförligare resonemang om nyckelkvalitét). Om det brister i nyckelkvalitét så är det där resan ska påbörjas på nytt. Det finns dessvärre ingen algoritm i världen som kan råda bot på ett dåligt grundarbete. Tyvärr.